home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01a.txt / 000055_icon-group-sender _Mon Jun 12 08:47:45 2000.msg < prev    next >
Internet Message Format  |  2002-01-03  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA19788
  4.     for icon-group-addresses; Mon, 12 Jun 2000 08:47:29 -0700 (MST)
  5. Message-Id: <200006121547.IAA19788@baskerville.CS.Arizona.EDU>
  6. From: Steve Wampler <swampler@noao.edu>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: User defined operators for Icon
  9. Date: Tue, 06 Jun 2000 08:36:26 -0700
  10. X-Trace: noao.edu 960305789 18654 140.252.38.6 (6 Jun 2000 15:36:29 GMT)
  11. X-Complaints-To: abuse@noao.edu
  12. X-Accept-Language: en
  13. To: icon-group@optima.CS.Arizona.EDU
  14. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  15. Status: RO
  16. Content-Length: 2383
  17.  
  18. "Frank J. Lhota" wrote:
  19. > 
  20. > Languages such as C++ and Ada permit the programmer to define the behavior
  21. > of operators and predefined functions for user defined types. Would it be
  22. > desirable to add such a capacity to Icon? If so, what would this facility
  23. > look like?
  24.  
  25. Well, I have an opinion, though unicon is probably the place to pursue this,
  26. as I don't see any major enhancements being made to Icon right now.  Perhaps
  27. whatever works in unicon could be backed into Icon later.
  28.  
  29. There are several parts (others probably have better ways to do this):
  30.  
  31. (1) Have keywords for every function (as apposed to procedures) that
  32.     always get you the "original" definition.  This would be useful
  33.     now as it would allow access to the original functions even when
  34.     procedure definitions attach new meanings to the names.  There
  35.     may be a problem where existing keywords match existing function
  36.     names - that would need to be resolved.
  37.  
  38. (2) Have keywords for every operand (e.g. &+, &:=, etc.) which would
  39.     act in the same way that string invocation of operators does now,
  40.     but always reference the original definitions for the operators.
  41.  
  42. (3) add a way to assign new definitions to operators, perhaps with
  43.     syntax:
  44.  
  45.     operator "+"(a,b)
  46.        ...
  47.     end
  48.  
  49.     where the number of parameters determines which operation is
  50.     being redefined [could even generate compile-time error if
  51.     no such operation exists].
  52.  
  53.     So, adding complex numbers could be (well, you could do better
  54.     than this, but it's a start):
  55.  
  56.     operator +(a,b)
  57.  
  58.        if (type(a) == "complex") & (type(b) == "complex") then {
  59.            return complex(a.x + b.x, a.y + b.y)
  60.            # or: return complex( &+(a.x, b.x), &+(a.y,b.y))
  61.            }
  62.        return &+(a,b)
  63.  
  64.     end
  65.  
  66. Or course, unicon, with its inheritance, may be able to provide
  67. considerably more flexibility, since the above scheme only allows
  68. one level of redefinition...
  69.  
  70. Why do I like this?:
  71.  
  72. (a) most of the mechanisms for implementing this are already in place.
  73.  
  74. (b) there are minimal syntactic changes to the language (even less if
  75.     you go with using the reserved work "procedure" instead of adding
  76.     the reserved work "operator").
  77.  
  78. (c) with proper implementation, there should be little, if any,
  79.     performance penalty involved.
  80.  
  81. --
  82. Steve Wampler-  SOLIS Project, National Solar Observatory
  83. swampler@noao.edu
  84.